There are many ways in which databases are currently architectured. The two main ones are: RDBMS (relational databases), ODBMS (Object databases). Both systems have been in existence for considerable length of time. RDBMS has enjoyed wider popularity than the ODBMS systems. However both have drawbacks.
Relational database management systems are widely used across industries to store and manipulate data. One of the main problems with relational databases has been the structural rigidity of data once defined using a data definition language (DDL). This has forced data to converge into silos of information each bounded by their own schema definition and each schema constructed for a specific purpose. This lack of integration has prohibited applications from taking advantages of the complex relationships between data from disparate sources and necessitated redundancy of data. The complexity of Online Transaction Processing (OLTP) vs. Online Analytical Processing (OLAP) systems and the conversion process between them is a direct case in point.
Some of the drawbacks of the RDBMSs are:
1. In case of the systems that use database cursors it is found that:                Application developers need to understand that the underlying data can change between the times that data records are accessed via the cursor: previously retrieved records may have been deleted, records may have been inserted into previously retrieved portions of the result set, or previously retrieved records may have been modified.         Not all cursors are created equal. Some cursors only allow forward scrolling.        Cursors are a resource drain on the database because they are memory intensive.        
2. In case of systems using Java Virtual Machines, it has been found that:                Different version of VMs between application server and database server increases complexity of development.        Behavior implemented in the database can easily become a bottleneck.        
3. RDBMSs use triggers. There are drawbacks associated with these:                Hand-crafted, or hand-modified, triggers can be difficult to maintain and will increase your dependency on your database vendor.        Triggers are typically implemented in a proprietary language requiring an extra skill set on your team.        Because triggers are automatically invoked they can be very dangerous (such as “uncontrolled” cascading deletions resulting from chained delete triggers).        Behavior implemented in the database can easily become a bottleneck if your database doesn't scale well.        
Another problem area while using RDBMSs is coupling. Coupling is a measure of the degree of dependence between two items—the more highly coupled two things are the greater the chance that a change in one will require a change in another. Coupling is a major challenge when it comes to software development, and the more things that your database schema is coupled to the harder it is to maintain and to evolve. Further challenges that one faces with RDBMSs are:                1. Data integrity is difficult to ensure with shared databases. Because no single application has control over the data it is very difficult to be sure that all applications are operating under the same business principles.         2. Operational databases require different design strategies than reporting databases. The schemas of operational databases reflect the operational needs of the applications that access them, often resulting in a reasonably normalized schema with some portions of it denormalized for performance reasons. Reporting databases, on the other hand, are typically highly denormalized with significant data redundancy within them to support a wide range of reporting needs.        
Many of these issues exist because of the nature of the database architecture.
Thus, a database system that is fundamentally different in its architecture may overcome the drawbacks mentioned above.
Some drawbacks of the ODBMSs are:                1. Rigid schemas with constraints need to be defined in advance.        2. All instances of objects have same predefined properties.        3. OLAP processing is inefficient.        
There is therefore a need to provide a database that successfully addresses the various drawbacks of the existing database models, and provides a robust, flexible, and secure database.